第 N 章 · 待总稿编排
StoryCam Development Session
漫画化视频链路、私有媒体流与首次私有发布
本 session 从片段生成逻辑追问开始，最终完成 StoryCam 的 Supabase 私有媒体规划、Seedance 真实链路判断、漫画风格产品转向、视频/最终作品恢复修复，并将当前版本发布到 GitHub 私有仓库。
本 Session 摘要
这次在整个项目中的作用- 把“能生成片段”变成“可验证的视频产品链路”从分镜脚本、9 张分镜图、Seedance prompt、轮询和最终作品页面一路查到真实调用和私有存储。
- 确立 Supabase private Storage 为媒体主仓库用户上传、AI 图、Seedance clip、final work 都统一以 bucket/path/metadata 管理；浏览器和 provider 只拿短期 signed URL。
- 发现真人参考图与 Seedance 的关键限制真实人物脸部 reference 在当前路径下会被 provider 拒绝；虚拟人物 smoke 成功，促成产品路线转向漫画/动画角色。
- 把 MVP 收敛成“一个 15 秒片段”修正旧的三片段 UI、假播放按钮和最终作品缺失问题，让片段确认页与导出页都使用真实 video 预览。
- 修复恢复与续期体验解决最近项目丢失、9 张图恢复不完整、signed URL 过期导致图片坏图、退回前面步骤后不能回到已生成视频的问题。
- 完成工程发布动作提交当前版本，并在 GitHub 账号下创建 private repo 后推送 `main`。
时间线
按对话推进顺序整理“storycam/clip-generation，有了分镜脚本和 9 张分镜图进入这个视频生成板块后，现在的业务逻辑是什么？”
Codex 总结：梳理片段生成入口：核心分镜组不是装饰图，而是视频 clip group；9 帧图用于生成 Seedance 参考链。随后继续追问 Seedance prompt 是否参考了 `shanyin-director-master`。
结果 / 影响：视频生成不再只被看作一个按钮，而被拆解成“导演分镜包、图片 reference、provider 调用、任务状态、回存媒体”的完整流程。
“我感觉对于传进去的 9 帧图片动作的描述还不够，没有体现导演对镜头的把控，你需要多找找使用 seedance 的参考。”
Codex 总结：把 Seedance prompt 从普通画面描述推进到“导演九帧计划”：要求明确图片 1 至图片 9 的角色、动作、镜头、节奏、视觉连续性，并吸收外部 Seedance 使用参考，但不暴露完整 provider payload。
结果 / 影响：片段生成的核心不再是“把图传给模型”，而是把 9 张图组织成导演可控的时序镜头说明。
“本地发起请求有一段时间了，还没有拿到返回结果。”、“需要换成真实的 api 来测了（你来改下配置），还有视频生成慢，现在这个位置的轮询机制是不是不太合理，官方建议如何通信。”
Codex 总结：定位本地 502 / 慢返回：浏览器只应轮询 StoryCam 自己的 `generation_jobs`，不直接轮询 Seedance；Seedance 真实任务应由服务端保存 provider task id，再由服务端轮询或 webhook 更新状态。
结果 / 影响：确认 provider 通信边界。浏览器变成“看本地 job 状态”，服务端负责和外部 provider 的异步任务交互。
“是不是可以选择 supabase 的 bucket 存储项目的图片、视频等，生成环境后面也会换成 supabase，所以需要整体规划下。”
“还需要考虑本地测试和生产环境，除了 seedance 要用的素材和生成后素材的存储，还要考虑其他环节生成前后的大文件存储方案。”
Codex 总结：制定并实现 StoryCam Supabase 大文件与媒体存储规划：`storycam-uploads`、`storycam-generated`、`storycam-mock` 均保持 private；数据库只存 `storage_bucket` / `storage_path`；UI preview 默认 5 分钟，provider reference 默认 3600 秒。
结果 / 影响：StoryCam 的媒体体系从临时本地文件/公开 URL 风险，转为可迁移到 staging/prod 的私有存储架构。
“PLEASE IMPLEMENT THIS PLAN: StoryCam Supabase 大文件与媒体存储规划 … Bucket 全部保持 private … local-real / staging / production …”
Codex 总结：落地计划：增加 provider reference URL helper，阻止 localhost/127.0.0.1 的 Storage URL 进入 Seedance；图片、clip、final work 写回 `storycam-generated`；删除故事时覆盖 uploads/generated/mock 三类 bucket。
结果 / 影响：安全边界被写进代码与测试：provider key、signed URL、完整 prompt、原始 provider error 均不得进入日志或客户端响应。
“有在 supabase 云端建好对应的项目么？”、“你用 supabase cli 弄就行。”、“现在可以自行测试了吧？”、“本地测试，先不用登录是否可以？”
Codex 总结：建立 hosted Supabase dev/staging 用于 local-real 真实 provider 联调；本地允许受控 auth bypass，但不用于 production。随后修复“最近项目没有历史记录”和“核心分镜只恢复 1 张图而不是 9 张图”的恢复链路。
结果 / 影响：本地真实联调不再依赖本机 Storage URL；历史 session 能恢复核心分镜和扩展图，为后续继续生成视频打基础。
“为什么生成失败？” 截图显示片段生成到 100%，右侧为 `Provider request failed.`，任务状态 failed。
Codex 总结：拆查 provider 失败：9 张 reference、HTTPS signed URL、图片类型和 prompt 长度均不是根因。Seedance create-task 返回 400 / request rejected，结合官方限制判断：当前链路不能直接用真实人脸参考图生成视频。
结果 / 影响：失败从“网络/存储问题”被定位为“provider 内容能力/合规边界问题”，避免继续在无效方向上调参。
“真人如果不行，拟真人也不行么？”、“如果产品整体思路变变，走漫画人物路线是否可行？”、“或者再查查 Inference.sh 有 seedance 的 api 么？会受真人图像限制么？”
Codex 总结：调研并做 smoke：真实人物 reference 路线受限；官方虚拟人 asset 受账号/资产权限影响未跑通；纯 prompt 虚拟人物短片可生成。产品方向因此转向非写真人脸的漫画/动画角色。
结果 / 影响：StoryCam MVP 从“私人真人照片驱动视频”调整为“漫画化私密故事剧场”，保留导演能力但降低 provider 拒绝概率。
“如果不把含人脸分镜图作为 Seedance reference URL 传进去，那人物资产就没有用了吧？”、“那如果完全切到漫画风格，符合现在用的导演能力么”、“好，那按这个路线迭代。”
Codex 总结：确认人物资产仍有价值：资产图和分镜图不再追求真实人脸复刻，而服务于漫画角色一致性、服装、动作、道具和场景连续性。随后代码中统一增加漫画/动画视觉风格策略。
结果 / 影响：新增 `visualStylePolicy`，更新 story world、storyboard、clip prompt、mock 与 OpenRouter/DeepSeek provider 逻辑，使默认产物转向 stylized comic animation。
“视频生成了一个，但是没有办法点击，不知道对不对，然后不是改成一个 15s 的视频了么，所以不应该如图有三个片段，也没有生成最终作品的步骤。”
Codex 总结：定位前端仍停留在旧的三片段 UI：`ClipReview` 的播放按钮只是装饰按钮，`FinalWorkPanel` 也是假预览；`stitch-suggestion` 要求 generated clip 已 accepted，但页面没有确认落库动作。
结果 / 影响：将片段确认页改为单个真实 `video controls`，最终作品接口返回短期预览 URL；“生成最终作品”即视为确认 ready clip，不再因 pending reviewState 返回 400。
截图显示角色资产、核心分镜和 8 张扩展图变成坏图文本。“为什么会到前面的版本，pic 没有不显示了？”
Codex 总结：判断图片并未丢失，而是 private bucket signed URL 5 分钟过期，React 状态仍持有旧 URL，浏览器显示 `<img>` alt 文本。自动恢复最近 session 则解释了“回到前面的版本”。
结果 / 影响：增加媒体 URL 自动刷新、4 分钟续期、图片加载失败触发刷新，以及坏图隐藏兜底，覆盖资产图、核心图、扩展图和大图预览。
“退回前面两个板块，就没有办法返回已经生成视频的板块，还需要重新生成？”
Codex 总结：定位 restore 只恢复 story world / storyboard，没有恢复 `video_clip` job、generated clip preview、final work metadata，导致后续步骤不可达。
结果 / 影响：session restore 返回 `clipJob` 和 `finalWork`；如果 clip 已成功则恢复到片段确认，如果 final work 已存在则恢复到导出，用户不需要重跑视频生成。
“code-simplifier”
Codex 总结：按代码简化技能对近期改动做等价整理：合并重复 signed URL 恢复逻辑，抽出 restore current step 类型，清理前端 refresh effect 的依赖表达。
结果 / 影响：保持行为不变，但降低 restore / 媒体刷新相关代码的维护成本。
“然后 commit”
Codex 总结：执行 `git diff --check`、stage、commit。提交信息为 `Implement StoryCam comic video media flow`。
结果 / 影响：生成 commit `4d59548`，包含 StoryCam 媒体存储、漫画路线、9 帧、视频恢复、最终作品与测试文档改动。
“好，在我的 github 里建一个私有的项目，并把现在这版推上去。”
Codex 总结：检查 `gh auth status`，确认登录账号为 `nlp-zn`；创建 private repo `nlp-zn/storycam`，设置 `origin`，推送当前 `main`。
结果 / 影响：StoryCam 当前版本完成首次 GitHub 私有发布。仓库 URL：`https://github.com/nlp-zn/storycam`，visibility 为 private。
关键时刻
判断、取舍与根因1. 私有媒体架构成为主线
- 问题
- 图片、视频、provider reference、最终作品分散在不同临时链路里，本地测试与生产部署边界不清。
- 为什么重要
- StoryCam 是私密故事产品，媒体素材天然敏感。公开 URL、长期链接或日志泄露都会破坏产品信任。
- 处理
- 统一 Supabase private buckets，仅存 bucket/path metadata；UI 和 provider 分别使用不同 TTL 的 signed URL。
2. Seedance 失败改变产品路线
- 问题
- 真实人脸参考图生成视频时，Seedance 创建任务失败，返回脱敏后的 provider request failed。
- 为什么重要
- 如果继续把真实人脸 reference 作为 MVP 主链路，产品会在核心生成节点不稳定。
- 处理
- 通过排除存储、URL、类型、prompt 长度等问题后，判断是 provider 能力/合规限制；转向漫画人物路线。
3. MVP 收敛为一个 15 秒片段
- 问题
- 旧 UI 仍显示三个片段卡，播放按钮是假按钮，最终作品步骤实际不可用。
- 为什么重要
- 用户已经等待真实视频生成，如果结果不能播放、不能进入最终作品，会直接破坏验收闭环。
- 处理
- 改成单个 15 秒真实视频预览；final work 返回真实短期预览；`生成最终作品` 同时承担确认动作。
4. Restore 必须恢复“进度”，不只是恢复“素材”
- 问题
- 用户退回前面步骤后，左侧片段生成、片段确认、导出不可点击，看起来只能重新生成。
- 为什么重要
- 视频生成成本高、耗时长；任何丢进度的体验都会让用户误以为资产失效。
- 处理
- session restore 以 metadata 为准恢复最新 video job、generated clip preview 和 final work。
5. Signed URL 过期不是数据丢失
- 问题
- 图片显示成 alt 文本，用户以为回退版本或图片丢失。
- 为什么重要
- private Storage 必然使用短期 URL，产品必须把续期做成基础能力。
- 处理
- 自动刷新媒体 URL、图片加载失败触发刷新，并隐藏坏图文本，避免视觉层面的“破图”。
工程证据
命令、提交、验证和发布Commit / Repo
- Commit:
4d59548 Implement StoryCam comic video media flow - GitHub private repo:
nlp-zn/storycam - Remote:
origin https://github.com/nlp-zn/storycam.git - Branch pushed:
main - PR: 本 session 未创建 PR。
关键文件
src/lib/storycam/visualStylePolicy.tssrc/server/storycam/mediaStore.tssrc/server/storycam/generationJobService.tssrc/server/storycam/finalWorkService.tssrc/server/storycam/sessionRestoreService.tssrc/components/storycam/ClipReview.tsxsrc/components/storycam/FinalWorkPanel.tsxsupabase/migrations/20260507102000_generation_job_provider_failure_metadata.sql
验证记录
pnpm typecheck: passedpnpm vitest run ...: 多组 API / provider / restore 测试通过pnpm playwright test ... storycam-final-work / storycam.visual: passedpnpm playwright test ... storycam-restore / storycam-final-work: passedgit diff --check: passed
Provider 证据
- 真实人物 reference: Seedance create-task 失败，错误已脱敏。
- 虚拟人物 / 纯 prompt smoke: 可生成短视频，但具体 provider task id 与下载 URL 不记录。
- Inference.sh / Seedance 调研: 作为产品路线判断输入，未确认能规避真人脸部限制。
安全与隐私
- API key / token / cookie / provider payload: [REDACTED]
- Supabase signed URL: [REDACTED]
- 原始 provider error: 仅保留脱敏摘要。
- 用户素材: 不嵌入文档，仅描述其在调试中的意义。
部署状态
- GitHub 私有仓库已创建并推送。
- Supabase hosted dev/staging 项目已用于 local-real 联调。
- Production 部署、域名、正式 CI release：本 session 未确认 / 待补充。
对外讲解用总结
可直接讲给别人听这次 session 是 StoryCam 从“能不能调用视频模型”走向“能不能作为一个私密视频产品闭环”的关键转折。我们先把 9 帧分镜进入 Seedance 的链路讲清楚，然后发现真实人脸 reference 在当前 provider 路径下不可稳定作为 MVP 主方案，于是把产品方向调整为漫画/动画人物路线。与此同时，我们把 Supabase private Storage 作为媒体主仓库，解决素材、生成图、视频片段、最终作品的存储和预览问题。最后，我们修复了多个真实使用中暴露的问题：视频生成后不能播放、旧三片段 UI、不生成最终作品、signed URL 过期导致破图、退回前面步骤后丢失已生成视频进度。这个 session 的结果是：StoryCam 拥有了更合理的漫画化视频生成路线、私有媒体安全边界、可恢复的用户进度，并发布到了 GitHub 私有仓库，成为后续 staging / production 工作的基础版本。